-
Notifications
You must be signed in to change notification settings - Fork 252
Deprecate override in favour of triage #2005
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR deprecates the legacy override functionality in favor of a new triage configuration for issue transformation. Key changes include the introduction of the triage module with new configuration structures, removal of unused override logic, and updates to the planner to build triages from both triage and legacy override settings.
Reviewed Changes
Copilot reviewed 7 out of 13 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
qlty-config/src/config/triage.rs | Introduces new triage configuration and implementation. |
qlty-config/src/config/overrides.rs | Deprecates override functionality by removing redundant code. |
qlty-config/src/config.rs | Re-exports the new triage components and updates module order. |
qlty-cli/tests/cmd/check/triage.toml | Adds a test configuration for triage. |
qlty-cli/tests/cmd/check/triage.in/.qlty/qlty.toml | Updates TOML config to include triage settings. |
qlty-cli/tests/cmd/check/override.in/.qlty/qlty.toml | Retains a legacy override test configuration with a deprecation notice. |
qlty-check/src/planner.rs | Modifies the plan builder to prefer triage over override. |
Files not reviewed (6)
- qlty-cli/tests/cmd/check/override.stderr: Language not supported
- qlty-cli/tests/cmd/check/triage.in/.gitignore: Language not supported
- qlty-cli/tests/cmd/check/triage.in/sample.sh: Language not supported
- qlty-cli/tests/cmd/check/triage.in/sample2.sh: Language not supported
- qlty-cli/tests/cmd/check/triage.stderr: Language not supported
- qlty-cli/tests/cmd/check/triage.stdout: Language not supported
Comments suppressed due to low confidence (2)
qlty-cli/tests/cmd/check/triage.in/.qlty/qlty.toml:17
- The key 'match.plugin' does not match the expected field name 'plugins' in the Triage configuration. Consider updating this key to 'plugins' to ensure proper deserialization.
match.plugin = "exists"
qlty-cli/tests/cmd/check/triage.in/.qlty/qlty.toml:18
- The key 'match.rule' does not match the expected field name 'rules' in the Triage configuration. Please update this key to 'rules' for consistency.
match.rule = "fail"
Diff Coverage for macos-15: The code coverage on the diff in this pull request is 88.3%. Total Coverage for macos-15: This PR will increase coverage by 0.18%. File Coverage Changes
🛟 Help
|
Diff Coverage for ubuntu-latest: The code coverage on the diff in this pull request is 88.3%. Total Coverage for ubuntu-latest: This PR will increase coverage by 0.19%. File Coverage Changes
🛟 Help
|
❌ 1 blocking issue (1 total)
|
if let Some(path) = issue.path() { | ||
glob_set.as_ref().unwrap().is_match(path) | ||
} else { | ||
// TODO: Issues without a path are not filterable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub category: Option<String>, | ||
|
||
#[serde(default)] | ||
pub mode: Option<IssueMode>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think disabled
is allowed as an IssueMode
but should be rejected here. So I guess what we currently call "IssueMode" is really a plugin mode and an Issue Mode is a plugin mode except "disabled"
qlty-config/src/config/triage.rs
Outdated
pub level: Option<String>, | ||
|
||
#[serde(default)] | ||
pub category: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be an enum instead a string?
qlty-config/src/config/triage.rs
Outdated
#[derive(Debug, Serialize, Deserialize, Default, Clone, JsonSchema)] | ||
pub struct Set { | ||
#[serde(default)] | ||
pub level: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be an enum instead a string?
qlty-config/src/config/triage.rs
Outdated
pub struct Triage { | ||
#[serde(default)] | ||
#[serde(rename = "match")] | ||
pub _match: Match, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do r#match
as an alternative to _match
1375b77
to
d1f17c4
Compare
d1f17c4
to
f3e1818
Compare
qlty-types/src/lib.rs
Outdated
@@ -383,3 +387,65 @@ impl AddAssign for tests::v1::CoverageSummary { | |||
*self = *self + other; | |||
} | |||
} | |||
|
|||
impl JsonSchema for analysis::v1::Level { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of manually implementing the JsonSchema
trait, I think it would be better if we could have the Prost protobuf generator include a JsonSchema
in the derive
macro during codegen.
It looks like this is possible: tokio-rs/prost#1064
https://docs.rs/prost-build/latest/prost_build/struct.Config.html#method.type_attribute
However, before going down this rabbit hole, what I would recommend is that you manually edit the generated files to add JsonSchema
to the existing derive statements, so:
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, ::prost::Enumeration)]
#[repr(i32)]
pub enum Level {
Unspecified = 0,
Note = 10,
Fmt = 20,
Low = 30,
Medium = 40,
High = 50,
}
Becomes:
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, ::prost::Enumeration, JsonSchema)]
#[repr(i32)]
pub enum Level {
Unspecified = 0,
Note = 10,
Fmt = 20,
Low = 30,
Medium = 40,
High = 50,
}
If the manual edit works, then we just need to get Prost to output the code the way we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was concerned that manually modifying generated file will cause long term friction, every time the files are generated as JsonSchema would get removed and then someone would have to figure out the compile error put it back in place.
Even right now every time I make a change with protos I have to be careful to pick the changes intended and commit those, as it makes a lot of changes to the generated files every time I run the command.
@claude review this PR |
Claude finished @brynary's task —— View job I'll review this PR in detail. Here's my plan:
PR Review: Deprecate override in favour of triageThis PR replaces the existing Positive Aspects
Issues and Suggestions
These improvements would further enhance the quality of this well-structured PR. |
https://github.com/qltysh/cloud/issues/5925